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(54) Field device management system 

(57) The invention relates to field management in in- 
dustrial process systems and similar systems. In the in- 
vention, maintenance management systems of industri- 
al processes of separate plants located geographically 
apart from each other are networked in such a way that 
they may communicate with each other and exchange 
information on maintenance parameters of field devices 
of different types. As a result, experience obtained in 



one industrial process can be transferred to other re- 
spective industrial processes and applications. By uti- 
lizing this globally collected cumulative information, it is 
possible to improve and specify the diagnostics of the 
separate local maintenance systems (6) essentially 
faster than in case if the local maintenance manage- 
ment system were independent and the diagnostics 
were changed on the basis of local experience only 
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Description 

BACKGROUND OF THE INVENTION 



[0001] The invention relates to field device manage- 
ment in industrial process systems and similar systems. 

FIELD OF THE INVENTION 

[0002] Field devices for industrial processes general- 
ly signify regulating devices, control devices, sensors, 
transducers, and the like, directly connected to the proc- 
ess. A typical field device is a control valve provided with 
a valve controller, such as the valve controller ND800 of 
Neles Controls Oy. So-called intelligent field devices are 
provided with a control logic or software, which makes 
it possible to control the field device locally for instance 
by means of a suitable control algorithm, tocollect status 
and measurement data and/or to communicate with a 
field management system in accordance with a field 
communication protocol, such as HART (Highway Ad- 
dressable Remote Transducer). In addition, intelligent 
field devices contain that much diagnostics at present 
that a field device is capable of informing of its failure. 
This information can be utilized for recognizing the de- 
vice requiring maintenance, which reduces the mainte- 
nance costs because unnecessary device testings are 
avoided. More-over, the utilization ratio of a plant (fac- 
tory) increases when unanticipated shutdowns de- 
crease. 

[0003] Typical field management systems are PC pro- 
grams provided with graphical user interfaces and com- 
prising properties as follows: configuration of field de- 
vice, configuration database, maintenance control of 
field device on the basis of status data received from 
field device, and status database of field device. Exam- 
ples of commercial field management systems are: 
Field Manager manufactured by Fisher-Rosemount 
Inc.; Documint manufactured by Honeywell Inc.; Cor- 
nerstone manufactured by Applied Technologies Inc.; 
Smartvision manufactured by Elsag-Bailey. 
[0004] The maintenance control function is typically 
automatic and can be configurated by the user. At main- 
tenance control, a software scans the field devices as 
desired by the user and stores the status data desired 
by the user in the status database together with a time 
stamp. The status database can be browsed by means 
of a graphical user interface, which may be located an- 
ywhere in the plant. In this way, universal status data, 
which are very limited as far as e.g. maintenance data 
are concerned, are received from the field device. Sta- 
tus data items typically describing the condition of the 
device are: in condition and out of condition. This is often 
not enough for predictive or preventive maintenance. 
[0005] Plant operators use so-called control room ap- 
plications when running the plant by actual process con- 
trol automation systems. Because the operator monitors 
the process day by day, he could start a maintenance 
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step of a predetermined field device in time, if he were 
informed of the condition of said field device. A problem 
is to bring an information on a failure in a field device to 
the knowledge of the operator or maintenance person 
5 of the plant, because automation systems do not sup- 
port digital field communication protocols, such as 
HART. A reason for this is that they are primarily regard- 
ed as configuration protocols of a field device or the 
communication protocol does not support a transmis- 
10 sion of operating status data of the field device. The di- 
agnostics of the field device is clearly an area belonging 
to the field device supplier and not to the supplier of the 
actual automation system. The present control room ap- 
plications show only the data required for operating the 
1 * process, and the operator has to check the status of the 
field devices relating to said process in a separate field 
management software. To use a separate field device 
management software in the control room is problematic 
for the operator, because there is no connection be- 
20 tween the field devices displayed by the software and 
the process to be monitored. This leads to the fact that 
the operator primarily monitors the process and does 
not react to the condition of the field device until it caus- 
es interference with the process. 
25 [0006] The significance of diagnostics in intelligent 
field devices will continue to increase in a field bus en- 
vironment. It is then especially important that the field 
device management concept and also the outputs and 
reports provided by it are clear and simple enough for 
30 the users. The present methods are not simple and so- 
phisticated enough for this purpose. It is to be assumed 
that the two-way communication of the field devices will 
provide a flood of information in maintenance control 
software and automation systems. Accordingly, they 
35 rather increase the amount of work than decrease it. On 
the other hand, in order to achieve a simple and easy- 
to-use concept of diagnostics, the tools already existing 
in the control rooms should be utilized as much as pos- 
sible. User interfaces of new application programs are 
40 not desired in the control room, because they require 
further training and maintenance and increase the com- 
plexity of running and monitoring the process. Actually, 
a user-friendly diagnostic system should not be visible 
to the user as a software provided with a separate user 
4 5 interface at all. 



BRIEF DESCRIPTION OF THE INVENTION 



[0007] An object of the invention is a maintenance 
50 management of field devices, which is reliable, simple 
and easy to use for the user. 

[0008] This is achieved by a system for the mainte- 
nance management of field devices in industrial proc- 
esses, each of them comprising a local maintenance 
55 management system. The local maintenance manage- 
ment systems of said industrial processes being net- 
worked in order to exchange information relating to the 
maintenance of field devices for a network level learning 
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and utilization of the information, and at least one of the 
local maintenance management systems is arranged to 
modify maintenance management parameters inde- 
pendently based on both data collected locally and data 
received from other local maintenance management s 
systems.. 

[0009] Another object of the invention is a mainte- 
nance management system supervising field devices in 
industrial processes. The maintenance management 
system is arranged to to 

communicate with maintenance management sys- 
tems of industrial processes of other plants located 
geographically apart from each other, in order to 
transmit and receive information relating to the is 
maintenance management of the field devices, 
adjust maintenance parameters of the field devices 
independently in a self-learning manner based on 
both data collected locally and data received from 
other maintenance management systems. 20 

[0010] The basic idea of the invention is to network 
the maintenance management systems of industrial 
processes of separate plants located geographically 
apart from each other in such a way that they are capa- zs 
bio of communicating with each other directly and/or via 
a centralized maintenance management unit and trans- 
mitting information on maintenance parameters of dif- 
ferent field device types. Each local maintenance man- 
agement system is provided with an independent anal- 30 
ysis, self-learning and control capability and arranged 
to control local maintenance management parameters 
independently in a self-learning manner based on both 
data collected locally and on the information received 
from the other local maintenance management sys- 35 
terns. In this way the experience obtained from or ob- 
served in one industrial process can be transferred to 
other industrial processes and applications of similar 
plants as well. By utilizing this globally collected cumu- 
lative information, it is possible to improve and specify 40 
the diagnostics of the separate local maintenance man- 
agement systems essentially faster than in case if a lo- 
cal maintenance management system were a stand- 
alone system and the diagnostics were changed on the 
basis of local experience only. 45 
[0011] In an embodiment of the invention, the local 
systems communicate may also communicate with or 
through a centralized maintenance unit. A centralized 
unit (server) makes it easier to manage the information 
exchange as the addresses of the local systems can be so 
stored at the central unit only instead of maintaining 
dress list in each local system. Further, the information 
can be selectively forwarded to those local systems hav- 
ing similar field devices. Also the security functions can 
be improved as it is easier to verify the transmitting or ss 
receiving local system at the central unit. The central- 
ized unit may also analyze collected data by different 
statistical and mathematical methods and produce con- 



trol data, which are transmitted to all local systems in 
the network. This allows , a field device manufacturer 
may monitor all its field devices in different parts of the 
world and to use the cumulative statistical data for de- 
velopment of new products and for enhancing the oper- 
ation of the existing ones, so as to obtain optimal per- 
formance and optimal maintenance intervals, for exam- 
ple. The communication is preferably based on existing 
general methods, such as electronic mail, DDE, HTML, 
short message, Internet. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0012] The invention will now be described in more 
detail by means of preferred embodiments, with refer- 
ence to the attached drawings, in which 

Figure 1 shows a local maintenance management 
system of field devices connected to a process au- 
tomation system of a factory, 
Figure 2 shows components of a field agent accord- 
ing to a preferred embodiment of the invention, and 
Figure 3 illustrates a network of local maintenance 
management systems, i.e. field agents, according 
to the invention, and 

Figure 4A and 4B are graphical descriptors illustrat T 
ing a variation in values of a performance index and 
a maintenance need index as a function of time. 

DETAILED DESCRIPTION OF THE INVENTION 

[0013] The present invention can be applied to all in- 
dustrial processes or the like comprising intelligent field 
devices. Intelligent field devices signify here any device 
relating to a process or an automated system or a con- 
trol thereof which shall be controlled and which is capa- 
ble of producing information describing the condition of 
the device directly or indirectly, this information being 
known as condition data. A typical intelligent field device 
of this kind is a control valve provided with a valve con- 
troller. 

[0014] Figure 1 shows a general block diagram of a 
process automation system and, joined thereto, a main- 
tenance management system of field devices according 
to the invention. The automation system comprises con- 
trol room programs and databases 1 1 as well as process 
control programs and an I/O part 12. The control and I/ 
O part 12 is connected via buses in accordance with 
HART standard to intelligent field devices constituted by 
control valves 14, 15, 16 and valve controllers 1 4A, 1 5A, 
16A.The valve controller may be for instance an ND 800 
of Neles Controls Oy. HART (Highway Addressable Re- 
mote Transducer) is based on transmitting digital data 
together with a conventional 4 to 20 mA analog signal. 
HART enables a two-way communication, by means of 
which intelligent field devices can be controlled and data 
can be read from them. A HART protocol follows the ref- 
erence model of a protocol stack by OSI (Open System 
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Interconnection), which model has been developed by 
International Organization for Standardization (ISO). In 
layers 7 (application layer), HART instructions are trans- 
mitted. A HART instruction set contains universal com- 
mands understood by all field devices and device-spe- 
cific commands providing functions which are restricted 
to an individual device (device type). The HART protocol 
enables a point-to-point configuration, in which there is 
a separate bus (pair of wires) between each field device 
and a master unit, or a multidrop configuration, in which 
up to 15 field devices are connected to the same field 
bus (pair of wires). The HART protocol is described in 
greater detail for instance in the publication HART Field 
Communication Protol: An Introduction for Users and 
Manufacturers, HART Communication Foundation, 
1995. The HART protocol has also become industrial 
standard. However, it is to be understood that the type 
or implementation of a field communication interface, i. 
e. the field bus and the protocol used by it, is not signif- 
icant for the present invention. 

[0015] The condition of field devices is monitored by 
means of a field device maintenance management sys- 
tem 1 0 according to the invention, which system collects 
data from the field devices. For this purpose, each field 
device 14, 15 and 16 is connected via a respective field 
bus to a conventional HART multiplexer 9, which again 
is connected via an RS-485 bus 8 to a PC 6. The oper- 
ating system of PC 6 is Windows 95/98 or Windows NT, 
for instance. Moreover, a work station 6 is connected to 
a local area network LAN of the factory (over which net- 
work it may communicate with control room software, 
for example). 

[0016] The work station 6 contains a maintenance 
management software for field devices. The purpose of 
the software is to collect data from the intelligent field 
devices 14 to 16. This data collecting is fully automatic 
and requires no staff. On the basis of the collected data, 
the condition of the device can be analyzed and a mes- 
sage informing of the condition can be sent to another 
system, such as to the other parts of the automation sys- 
tem of the factory, e.g. to the display of a control room 
application. 

[0017] Figure 2 is a general block diagram illustrating 
components of the field device maintenance manage- 
ment system or software according to a preferred em- 
bodiment of the invention. 

[0018] Device modules are independent program 
components using a field bus in a manner they desire. 
A device module preferably is specific for each device 
type (not device-specific). For instance, two different 
control valves or control valves of different manufactur- 
ers may represent different types of device. Two identi- 
cal field devices having different uses or wanting to mon- 
itor different matters may also belong to different device 
types. Generally, field devices requiring mutually differ- 
ent applications (device agents) for collecting and ana- 
lyzing data and for producing status data can be classi- 
fied to different device types. A device module contains 



all necessary data and instruction sets for reading, an- 
alyzing and/or processing the status and diagnostic data 
of field devices of a predetermined type and also for pro- 
ducing status data for the device. Moreover, the device 
5 module 22 may store collected raw data and condition 
data of the device derived from them in a device data- 
base 24 for a later use. A more accurate diagnosis of 
the field device may then be made on the basis of the 
raw data by device-specific software, as by Valve-Man- 
io ager in the case of ND800 valve controller. The device 
modules 22 have a simple interface to a software core 
25, over which the device module 22 may send data and 
an information on the status or condition of each field 
device to the core 25. It is also possible that an intelligent 
is field device analyzes its condition itself whereby the raw 
data received over the field bus already is processed to 
some extent. In this case, the device module 22 may 
process the data further, for instance on the basis of the 
data it has received from the process automation sys- 
20 tern, or transmit the data as such to the core 25. 

[0019] The software core 25 comprises a timer and a 
management of device modules and field devices. The 
task of the timer is to give each device module 22 sep- 
arately a permission to use the HART field bus. The pri- 
25 ority level of the field devices can be changed, whereby 
a higher number of data retrieval accesses in a time unit 
may be given to a predetermined field device than to 
another field device. The number of the device-specific 
priority levels may be for instance four: no data are re- 
30 trieved from the field device, data are retrieved from the 
field device normally, data are retrieved from the field 
device twice as often as normally and data are retrieved 
from the field device four times as often as normally. Ad- 
ditionally, the timer may give the device module 22 a 
35 permission to collect timed data from the field devices 
at suitable intervals, for instance once an hour, a day, a 
week, a month or a year, which data are not urgent, but 
useful for preventive maintenance, for instance. 
[0020] For the maintenance management of the de- 
40 vice agents, the core 25 contains data of the device 
modules 22 of the system. For the field management, 
the core 25 contains data of the field devices subjected 
to the management of each device module 22. 
[0021] The core 25 forwards data and status data to 
45 an analyzing block 21 and to a status checking block 23 
and may receive adaptation instructions from the ana- 
lyzing block 21 for changing the priority level of a pre- 
determined device, for instance. 

[0022] The status checking block 23 preferably stores 
50 the status data, transmitted by the device modules 22 
via the core 25, in a field device-specific database. In 
other words, the status data of each field device are 
stored separately in the block 23. When the status 
checking block 23 receives the status data of a prede- 
55 termined field device from the device module, it com- 
pares this status data with the preceding status, which 
is stored in the respective field device database in the 
checking block 23. If the status has changed, i.e a 
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change has occurred in the condition ol the field device, 
the checking block 23 sends the changed status data 
forward over an open communication interface, where- 
by the change in the condition of the field device appears 
at the user interface of the control room application, for 
instance. Such a transmission principle is called excep- 
tion-based, because only the changes in the field device 
status are informed forward. The checking block 23 
transmits the status messages to one or more report 
modules 26, 27, 28. 

[0023] The analyzing block 21 analyzes the condition 
of the field devices on the basis of the data received 
from the core and utilizing knowledge data stored in a 
database 29. In a preferred embodiment of the inven- 
tion, the field devices to be managed are control valves, 
and the analyzing block 21 determines two indexes de- 
scribing the operation and condition of a control valve 
on the basis of the collected data: control performance 
index and maintenance need index. 
[0024] The control performance index is a key when 
estimating the operation of a control valve from the view- 
point of the whole industrial process. It is used for trying 
to estimate the effect of the valve on process variability. 
The control performance index may also contain appli- 
cation-based data, e.g. whether the process is fast or 
slow. In a fast process, it is for instance important that 
the control valve responds to a control signal rapidly. In 
a slow process, respectively, a small static control error 
of the control valve is significant. 

[0025] The maintenance need index, in turn, informs 
of the need of maintenance of control valves. The need 
of maintenance may be caused either by mechanical 
factors, such as wear, or by poor control performance 
itself. A wider diagnostics of a control valve associated 
with the use of the maintenance need index tries to lo- 
cate also the source causing the maintenance need of 
the control valve, i.e. the object of maintenance. 
[0026] The analyzing block 21 determines the control 
performance index and the maintenance need index by 
utilizing an expert system, whose inputs are compo- 
nents affecting the indexes. These components are: da- 
ta to be collected from the field devices and application- 
based and device-/device type-specific knowledge (ex- 
pertise) received from the knowledge database 29. This 
knowledge consists in the knowledge the field agent it- 
self has learned and collected and, according to the ba- 
sic idea of the invention, in the experience collected by 
other field agents in other industrial processes and in 
the knowledge of the performance and maintenance 
need of the control valves. 

[0027] The valve controller is capable of collecting a 
large amount of different data concerning the control 
performance of the valve. The majority of the collected 
data is of on-line type, naturally. The most important pa- 
rameters affecting the control performance and collect- 
able at present already are: static error, rate of change 
in static error, dynamic error, rate of change in dynamic 
error, opening accumulation, load and rate of change in 



load. Correspondingly, examples of components affect- 
ing the maintenance need index are: control perform- 
ance, odometer of valve, odometer of actuator, number 
of valve reversals, number of actuator reversals, valve 

s seal leakage, valve emission, valve wall thickness, cav- 
itation level, load and rate of change in load. 
[0028] By drawing the control performance index and 
the maintenance need index graphically, it is possible to 
give the user a clear picture of the operation and condi- 

10 tion of the valve. It is even possible to program the an- 
alyzing block 21 to predict how the indexes develop as 
a function of time. Figure 4A is an example of the devel- 
opment of the performance index as a function of time. 
P1 is the minimum acceptable level, i.e. the threshold 

*5 level, below which an alarm and a maintenance step are 
caused. Figure 4B is an example of the development of 
the maintenance need index as a function of time. Ml 
is the maximum level of the maintenance need, i.e. the 
threshold level, above which an alarm and a mainte- 

20 nance step are caused. 

[0029] The analyzing block 21 (as the whole field 
agent) is an independent component, which does not 
need outside impulses to operate. Upon commission- 
ing, it monitors regularly, fully independently, the condi- 

2S tion of all field devices, such as control valves, connect- 
ed to the field bus. The analyzing block 21 and the whole- 
field agent are also capable of being adapted to chang- 
ing circumstances. An example of changing circum- 
stances is a weakening performance of a predetermined 

30 control valve. A learning block 20 then changes the ad- 
aptation of an analyser in the knowledge database, the 
analyzing block 2 1 gives the core 25 a new control signal 
"adaptation", as a result of which the core 25 subjects 
said control valve to a closer monitoring ; by raising its 

35 priority level, for instance, so that an alarm of a malfunc- 
tion can be given in time. 

[0030] The analyzing block 21 also gives analyzing 
results to report modules to be reported forward. 
[0031] Though a field agent operates independently, 

40 as far as users are concerned, it maintains, however, 
connections according to the invention to other field 
agents directly and/or via a centralized unit, known as 
a field agent server 30, as shown in Figure 3. This is 
indicated in Figure 2 by a learning module 20. When the 

45 analyzing block 21 finds a new information (e.g. a sud- 
den failure of a control valve of a predetermined type in 
certain circumstances) which could be of significance 
for the operation of the other field agents as well, it gives 
the information to the learning block 20. The learning 

50 block 20 sends the information by a suitable communi- 
cation method, such as electronic mail, DDE, HTML, 
short message, Intranet, Internet, to the field agent serv- 
er 30. For this purpose, the learning module 20 may use 
report modules 26 to 28. The field agent server 30 de- 

55 livers (multicasts) the information by a suitable commu- 
nication method, such as electronic mail DDE : HTML, 
short message, Intranet, Internet, to the relevant ones 
of the field agents 6 or to the whole (e.g. world-wide) 



5 



JSDOCJD: <EP 0965897A1_L> 



9 



EP 0 965 897 A1 



10 



network of field agents 6. Before forwarding the infor- 
mation, the field agent server preferably verifies that the 
message have been received from an authorized local 
system. This may be based on an encrypted electronic 
signature, for example. The field agent server may also 
analyze the information in order to find the relevant field 
agents which might use the specific information. The 
field agent server maintains at least a list addresses of 
the field agents, and preferably also configuration data 
of the local systems in order to enable the screening of 
the messages prior to forwarding them. The field agent 
server may also be provided with a knowledge database 
31 for a centralized collection and analysis of the per- 
formance and maintenance data 
[0032] The learning block of each addressed field 
agent 6 receives the information and, preferably upon 
verifying that the message is from the field agent server 
30 and thereby likely to contain reliable information, the 
field agent 6 transfers the information to the knowledge 
database 29 for indenpendent analysis and learning. It 
will thus be automatically included in the data used by 
the analyzing block 21. If, for example, the analyzing 
block 21 detects an information on a weakening per- 
formance of a valve of a predetermined type in certain 
circumstances in the knowledge database 29, it may 
change the priority level of control valves of this type, i. 
e. the reading rate in the core 25. The information may 
also be a new threshold level P1 or M1, in which case 
the alarm limits of a field agent are controlled on the ba- 
sis of information received from elsewhere. For remote 
control purposes, it may be possible for the field agent 
server 30 to send a specific instruction in consequence 
of which the field agent 6 changes its operation in a de- 
sired manner. 

[0033] In the above example, the field agent server 
30 controls the information and communication sent by 
the field agents 6. Alternatively, the field agents may 
communicate with each other directly. In the above ex- 
ample, when the analyzing block 21 finds a new infor- 
mation (e.g. a sudden failure of a control valve of a pre- 
determined type in certain circumstances) which could 
be of significance for the operation of other field agents 
as well, it gives the information to the learning block 30. 
The learning block 20 locates the information in the 
knowledge database of the agent and transmits the in- 
formation by a suitable communication method, such as 
electronic mail, DDE, HTML, short message, Intranet, 
Internet, to the whole (e.g. world-wide) network of the 
field agents 6. The learning block of each field agent 6 
receives the information and transfers it to the knowl- 
edge database 29, as was described above. This ap- 
proach, however, requires that the addresses of all field 
devices are stored at each field agent, which is rather 
difficult to manage in practice. Also security problems 
may arise, as the field agent should be able to verify that 
the received information is really coming from a reliable 
source. 

[0034] With reference to Figure 2 again, a report mod- 



ule is a program component whose task is to change a 
status message to a format understood by another sys- 
tem. The other system may be for instance a database, 
a control room of an automation system or a mainte- 
5 nance reporting system. Report modules 26 to 28 pro- 
vide an open communication interface with the other 
system. Open communication interface signifies for in- 
stance that the communication method by which the da- 
ta of the field devices are transferred to the other system 
10 is independent of the type of field device and the nature 
of field communication interface. A report module may 
be for instance an electronic mail program 27 sending 
the status data of the field device as an e-mail report to 
the other system. A report module may also be for in- 
'5 stance a WWW (World Wide Web) server 26 creating 
an HTML report from the maintenance data of the field 
devices, which report is offered as a WWW page. The 
other system may then read the WWW page with a com- 
mercial browser via Intranet or Internet. A report module 
20 may also create an HTML report or another text-based 
report, which is sent to the other system. A report mod- 
ule may also store the created (for instance text-based) 
report in the database, from where it can be read. A re- 
port module may also be a DDE server 28 communicat- 
es jng with the control room or other systems over a local 
area network LAN, for instance. The report modules 26, 
27 and 28 are preferably Windows programs, possibly 
commercial programs. Between the blocks 21 and 23 
and the report modules 26 to 28, there is then preferably 
30 an interface according to the Distributed Component 
Object Model (DCOM), over which interface an event 
message informing of the condition of the field device 
can be transmitted to the report modules 26 to 28. 
[0035] The blocks 21 and 23 transmit the data to be 
35 reported to a report module for instance as a text-based 
report or file, which the report module inserts for in- 
stance as the content of an e-mail message or a short 
message (e.g. GSM), which message it sends to a pre- 
determined address or several addresses. Correspond- 
*o ingly, the report module may change the content of the 
HTML/WWW page on the basis of the received text- 
based data. Internet and Intranet are TCP/IP networks 
known per se, the most significant application of which 
is WWW, but which also offer other data communication 
45 services applicable to the purpose of the present inven- 
tion. These are all well-known data transmission tech- 
nologies, detailed information and commercial applica- 
tions of them being available, for which reason it is not 
necessary to describe them here any further. On the 
so whole, the basic idea of the open communication inter- 
face concept of the present invention is that any general 
data transmission technology supported by another sys- 
tem may be applied as an open interface. 
[0036] It is obvious that, as the technique develops, 
55 the basic idea of the invention may be implemented in 
many different ways. Consequently, the invention and 
its embodiments are not restricted to the above exam- 
ples, but they can vary within the scope of the claims. 
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Claims 

1 . A system for the maintenance management of field 
devices in industrial processes, each of said indus- 
trial processes comprising a local maintenance 
management system, characterized in that 

the local maintenance management systems of 
said industrial processes being networked in 
order to exchange information relating to the 
maintenance of field devices for a network level 
learning and utilization of the information, 
at least one of the local maintenance manage- 
ment systems is arranged to modify mainte- 
nance management parameters independently 
based on both data collected locally and data 
received from other local maintenance man- 
agement systems. 

2. A system according to claim 1 , characterized in that 
the local maintenance management system com- 
prises 

a knowledge database storing application-spe- 
cific and/or device-specific and/or device-type- 
specific knowledge, 

analyzing means for analyzing the condition of 
the field devices based on a measurement data 
from the respective industrial process and a 
knowledge data from the knowledge database 
and, when necessary according to the analysis 
results,. for changing the maintenance parame- 
ters in the local maintenance management sys- 
tem, and 

means for modifying the contents of the knowl- 
edge data base according to both a mainte- 
nance history data collected locally and main- 
tenance history data received from other local 
maintenance management systems. 

3. A system according to claim 1 or 2, characterized 
in that said maintenance parameters include data 
representing a control performance of the field de- 
vices and/or the need of maintenance of the field 
devices. 

4. A system according to claim 1 , 2 or 3, characterized 
in that said maintenance parameters include a 
maintenance alarm limit and/or a performance 
alarm limit for the field device. 

5. A system according to claim 1 , 2, 3 or 4, character- 
ized in that said maintenance parameters include a 
maintenance priority level for the field device. 

6. A system according to claim 1 , 2, 3, 4 or 5, charac- 
terized in that said knowledge data include data rep- 
resenting a control performance history data of a 



field device and/or a field device-type and/or a proc- 
ess control application. 

7. A system according to claim 1 , 2, 3, 4 or 5, charac- 
s terized in that said knowledge data include data rep- 
resenting a maintenance need history data of a field 
device and/or a field device-type and/or a process 
control application. 

io 8. A system according to any one of claims 1 -7, char- 
acterized in that the field device is a valve and the 
parameter representing the performance compris- 
es or is affected by one or more of the following fac- 
tors: static error, rate of change in static error, dy- 

75 namic error, rate of change in dynamic error, open- 
ing accumulation, load, rate of change in load. 

9. A system according to any one of claims 1 -8, char- 
acterized in that the field device is a valve and the 

20 parameter representing the need of maintenance 
comprises or is affected by one or more of the fol- 
lowing factors: control performance, odometer of 
valve, odometer of actuator, number of valve re- 
versals, number of actuator reversals, valve seal 

25 leakage, valve emission, valve wall thickness, cav- 
itation level, load, rate of change in load. 

10. A system according to any preceding claim, char- 
acterized in that the local maintenance manage- 

30 ment system is arranged to independently adapt the 
maintenance management to the changes the man- 
agement system has detected in the properties of 
the field devices. 

35 11. A system according to any preceding claim, where- 
in the communication is based on one or more of 
the following communication methods: electronic 
mail, Dynamic Data Exchange, Hyper Text Markup 
Language, short message, Internet, OLE. 

40 

12. A maintenance management system for managing 
field devices in an industrial process, characterized 
in that said maintenance management system is ar- 
ranged to 

45 

communicate with maintenance management 
systems of industrial processes of other plants 
located geographically apart from each other, 
in order to transmit and receive information re- 
50 lating to the maintenance management of the 

field devices, 

adjust maintenance parameters of the field de- 
vices independently in a self-learning manner 
based on both data collected locally and data 
55 received from other maintenance management 

systems. 

13. A system according to claim 12, characterized in 
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methods: electronic mail. Dynamic Data Exchange, 
Hyper Text Markup Language, short message, In- 
ternet. 

5 



10 



15 



20 



25 

15. A system according to claim 12, 13 or 14, charac- 
terized in that said maintenance parameters include 
a maintenance alarm limit and/or a performance 
alarm limit for the field device. 30 

16. A system according to claim 12, 13, 1 4 or 15, char- 
acterized in that said maintenance parameters in- 
clude a maintenance priority level for the field de- 
vice. 35 

17. A system according to claim 12, 13, 14, 15 or 16, 
characterized in that said knowledge data include 
data representing a control performance history da- 
ta of a field device and/or a field device-type and/or 40 
a process control application. 

18. A system according to claim 12, 13, 14, 15 or 16, 
characterized in that said knowledge data include 
data representing a maintenance need history data 45 
of a field device and/or a field device-type and/or a 
process control application. 

19. A system according to one of claims 12-18, charac- 
terized in that the maintenance management sys- 50 
tern is arranged to independently adapt the mainte- 
nance management to the changes the manage- 
ment system has detected in the properties of the 
field devices. 

ss 

20. A system according to any one of claims 12-19, 
characterized in that the communication is based 
on one or more of the following communication 
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that the maintenance management system com- 
prises 

a knowledge database storing application-spe- 
cific anoVor device-specific and/or device-type- 
specific knowledge, 

analyzing means for analyzing the condition of 
the field devices based on a measurement data 
from the respective industrial process and a 
knowledge data from the knowledge database 
and, when necessary according to the analysis 
results, for changing the maintenance parame- 
ters in the maintenance management system, 
and 

means for modifying the contents of the knowl- 
edge data base according to both a mainte- 
nance history data collected locally and main- 
tenance history data received from other main- 
tenance management systems. 

1 4. A system according to claim 1 2 or 1 3, characterized 
in that said maintenance parameters include data 
representing a control performance of the field de- 
vices and/or the need of maintenance of the field 
devices. 
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